\documentclass[a4paper]{article}

\title{Network Security PS1 - Problem 1}
\date{\today}
\author{Paul Ozog}

\usepackage[pdftex]{graphicx}

\begin{document}

\maketitle

\section{Initial Setup}
Before beginning my connection the web server at http://www.northeastern.edu, my computer is connected to a local network with a properly configured Ethernet interface.  Let us pretend that the IP address is 192.168.1.148 with the default Class C subnet mask, and the Default Gateway is 192.168.1.1.  My computer's Address Resolution Protocol (ARP) table is empty.

\section{ARP Table}
Before resolving the host `www.northeastern.edu' using DNS, my computer must know how to reach the Default Gateway.  This is done with an internal ARP table or cache.  Because the ARP table is empty, there is no physical (MAC) address associated with the IP address of my home router (the Default Gateway for my setup).  To populate my computer's ARP table, it must send a ARP request broadcast to the entire local network.  

\subsection{ARP Broadcast}
My computer broadcasts an ARP packet to all nodes on the network, requesting that {\it``If you know how to reach 192.168.1.1, please tell 192.168.1.148.''}  The IP layer portion of the packet contains my computer's IP as the Sender and the default gateway as the Target.  Note that one step down in the network stack, the Ethernet layer denotes a broadcast as having destination ff:ff:ff:ff:ff as shown in {\bf Figure~\ref{fig:ARP}}.

\subsection{ARP Reply}
{\bf Figure~\ref{fig:ARP}} also shows the response to my computer's initial ARP request.  Note that the op-code of the second ARP packet is ``reply'' (0x0002) and the data informs my computer that the router can be reached at the specified MAC address.  After my computer's reception of packet 2, the ARP table is populated and my computer can proceed to the next step of the connection to www.northeastern.edu.

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=120mm]{arp.png}
    \caption{ARP Broadcast Packet}
    \label{fig:ARP}
  \end{center}
\end{figure}

\section{DNS}
Now that my computer knows how to reach the Default Gateway, I can resolve the server's hostname `www.northeastern.edu' to its IP address.  This is done by sending a DNS query on top of the UDP protocol on port 53.  The Default Gateway forwards this to the ISP DNS server, where the ``recursive address resolution mechanism'' begins.  The address resolution happens entirely in the Internet and thus my computer is not exposed to the mechanics of this process.  Eventually, my router receives the IP address of www.northeastern.edu (155.33.17.68), and forwards this information to my computer so the TCP handshake can begin.

\section{Establishing the TCP Connection}  
Establishing a TCP Connection is done with the ``three-way handshake.''  The handshaking between my computer and the remote site www.northeastern.edu happens in three packets as shown in {\bf Figure~\ref{fig:TCPHandshake}}.  My computer sends the first packet with the SYN flag raised to www.northeastern.edu on port 80.  The destination port is 80 because that is the port that the application layer uses (in this example, the HTTP server). The server responds with a TCP packet containing both a SYN and ACK to my computer's IP address and port (52568).  The ACK is to acknowledge my initial SYN request, and the SYN is to make sure that my computer did indeed initiate the TCP handshake.  Finally, my computer responds with an ACK, once again using destination port 80.  Now, the transport layer is set to allow the upper layers of the network stack reliable transfer of data.

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=120mm]{tcp-hs.png}
    \caption{DNS Query, TCP Handshake}
    \label{fig:TCPHandshake}
  \end{center}
\end{figure}

\section{The Upper Layers}
{\bf Figure~\ref{fig:HTTP}} demonstrates the role of the Transport layer in delivering data to and from the Application layer.  Inside the TCP packets, the Acknowledgment Number (``Ack'') and Sequence Number (``Seq'') fields show how the data between the two application processes is split and rearranged.  Note how the packets highlighted in black demonstrate the reliability of TCP.  For instance, if the data arrives out of order, TCP takes appropriate action without needing intervention from the upper layers (HTTP in this case).  Similarly, if a packet were lost in between the server/client application processes, TCP would act accordingly.  After receiving all of the necessary information from the web server, my computer sends a packet with the FIN flag raised, and the connection begins to close.  At this point, my computer would re-initiated a similar set chain events when I go to a separate site. 

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=120mm]{http.png}
    \caption{Web Content Packets}
    \label{fig:HTTP}
  \end{center}
\end{figure}

\end{document}

